[レポート]ニンテンドーアカウントリノベーションプロジェクト　CUS-20 #AWSSummit

ニンテンドーアカウント、皆さん持ってますよね？

AWS Summit Tokyo 2023

#移行

#AWS

べこみん

2023.04.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。

2023年4月20日〜21日に開催されているAWS Summit Tokyo 2023、皆さん参加してますか？

今回はそんな4年ぶりに開催されている最高のオフラインイベント、AWS Summit Tokyo 2023のセッションレポートを書いてみました。

さて皆さん、好きなゲームハードは何ですか？ゲームボーイ？ゲームボーイアドバンス？ゲームキューブ？

セッション概要

ニンテンドーアカウントリノベーションプロジェクト

ニンテンドーアカウントは 2015 年のリリース当初は Amazon EC2 を中心としたインフラ構成を採用していましたが、システム規模の拡大や時間の経過に伴い、徐々にシステムの継続性にリスクが生じるようになってきたため、リノベーション(システムの大規模な改修)を実施しました。
リノベーションではアプリケーションの実行基盤を Amazon EC2 から ECS on Fargate へ移行しつつミドルウェアについてもマネージドサービスを積極活用する方針で進めました。今回の発表では具体的にどのようにリノベーションを進めたのかをご紹介します。

登壇者

ニンテンドーシステムズ株式会社

ニンテンドーアカウント
府川幸太郎氏
川原貴裕氏
桑原健氏

レポート3行まとめ

ニンテンドーアカウントはEC2を中心とした環境で構築され、2015年にサービス開始した
機能追加を続けていくにつれ、だんだん運用や管理が辛くなってきた
一時的専門の移行チームを立ち上げ、システム無停止&新機能開発は継続でECS on Fargateやその他マネージドなAWSサービスに環境を置き換えた

レポート

セッション前に用事があったため、セッション開始前3分前ぐらいに会場に着くと、なんと既に立ち見でいっぱい。。。

この時点で任天堂さんの人気ぶりが伝わりますね。熱気が違います。

アジェンダはこんな感じ↓でした。

ニンテンドーシステムズ株式会社の紹介
ニンテンドーアカウントの紹介
リノベーションプロジェクトを発足した理由
リノベーションプロジェクトの詳細
まとめと展望

ニンテンドーシステムズ株式会社の紹介

ニンテンドーシステムズとは今回セッション登壇してくださった方々の会社で、任天堂とDeNAの合弁会社だそうです。

上記会社の設立自体は2023年ですが、もともと任天堂さんとDeNAさんは2015年に業務提携して「ニンテンドーアカウント」のバックエンド開発や運用を行っていたそう。

主な業務内容は「Nintendo Switch Online」や「どうぶつの森ポケットキャンプ」などの任天堂のネットワークサービス全般の開発・運用だそうです。

ニンテンドーアカウントの紹介

そもそも皆さんニンテンドーアカウントというものをご存知でしょうか。

ニンテンドーアカウントとは任天堂のサービスを利用するための共通の認証・認可基盤です。スマホやPC、Switchから共通で利用することが可能です。

また、ニンテンドーアカウントに関する数字としては下記のようなものがあります。

リリース
- 2015年
対象の国・地域
- 164
アカウント数
- 2.9億（2022年9月時点）

はい、めちゃくちゃ大規模なサービスですね。これがリノベーションプロジェクト発足の理由等に繋がります。。。

リノベーションプロジェクトを発足した理由

そもそも何故リノベーションプロジェクトが必要になったのでしょうか。

なんとこのニンテンドーアカウント、インフラ部分はAmazon EC2を中心に組まれていたそうです。

アプリケーションサーバーもEC2、DBもEC2、メール通知機能もEC2。。。

開発スピード（開発メンバーのスキル、ツールの存在）やコスト、柔軟性などの観点から、またリスクを下げて確実にリリースすることを重視してこのような構成に決まったそうです。ちなみにアプリケーションの開発言語はPerl。

そしてニンテンドーアカウントは2015年12月、この世に産声を上げます。

そして順調なリリースとともに成長を重ね、様々な機能の追加、多くの地域、ユーザーをサポートしていきます。（Switchに対応したのは2017年で、それより早い2016年にスマホゲームのスーパーマリオランでニンテンドーアカウントは使われたそうです。懐かしい。）

感のいい皆さんはもう嫌な予感がしてきましたね。そうです、次第に開発者は次のような課題にぶち当たります。

増え続けるトラフィック
予測できないスパイク
増大する運用工数
IaaS熟練者不足
引き継がれないノウハウ
Perlの求心力低下

辛いですね。。。サービスの成長にインフラが耐えられなくなってしまったのです。

そうです、これがリノベーションプロジェクト発足の理由です。

リノベーションプロジェクトの詳細

ということでニンテンドーアカウントリノベーションプロジェクトが発足します。

リノベーションの方針は下記

インフラ
- EC2→ECS on Fargateなどに置き換え
アプリケーション
- Perl→Javaで書き換え

さらに開発者の方々は下記のような目標を立てました。

継続性を高める
- オープンな技術の採用による属人化の低下
- 運用体制を考慮したIaCの構築
新規開発を継続する
- 開発チームとリノベーションチームの分離
無停止で乗り換える
- 各アプリケーションを段階的に移行

上述の通り、ニンテンドーアカウントは非常に多くのユーザーに利用される大規模サービスです。

もちろんサービスを停止することは出来ません。新規開発を継続するというのには私も驚きましたが、確かに元々リリース予定だった機能を延期し続けることは難しいですね。

※今回のセッションではインフラ部分のみの説明がありました。

リノベーションプロジェクトの体制

まずは体制から。

元々ニンテンドーアカウントのチームは各機能を開発する複数のサービスチームとインフラチームから成りました。

そこに新たに発足したのがリノベーションチームです。サービス開発は継続するため、各サービスチームとは別のチームが発足しました。

ここで私は面白いと思ったのが、このリノベーションチームが一時的なチームだということです。

ニンテンドーシステムズでは移行後の環境がリノベーションチームに属人化しないようにするために、このリノベーションチームを移行後解散する一時的な立ち位置のチームとしたのです。

リノベーションにて変化したもの

主にインフラ部分では以下のような移行を行ったそうです。

アプリケーション基盤
- 旧: Amazon EC2
- 新: Amazon ECS on AWS Fargate
データベース
- 旧: Amazon EC2（MySQL）
- 新: Amazon Aurora
メール送信
- 旧: Amazon EC2（Postfix）
- 新: Amazon SES
キューイングサービス
- 旧: Amazon EC2（Q4M on MySQL）
- 新: Amazon SQS

良い感じにコンテナ化&マネージド化出来ていますね。

また、下記については独自ツールを脱却してAWSサービスに置き換えたそうです。

クレデンシャル管理
- 移行後: AWS Secrets Manager
ミドルウェア設定管理
- 移行後: ECS Task, Amazon S3
システムアラート
- 移行後: Amazon CloudWatch, Amazon SNS

リノベーションの順序

今回の目標（マスト）はシステムの無停止です。

そのため、まずはSQSやDB系を置き換えたそうです。そして新旧環境を用意します。

その後、遂にFargateへの移行です。EC2→Fargateへの移行は、流入するトラフィックを1%→3％→5%のように本当に少しずつ段階的に切り替えていったそうです。

そして遂に無停止での移行に成功！！

その他

また、今回リノベーションしたのはインフラ環境の構成だけではありません。

ニンテンドーアカウントの環境は本番環境や各機能の開発環境など約20種類ほど存在し、更に必要なスペックが環境ごとに異なるそう。

しかもニンテンドーアカウントのサービス（機能）は全部で約10種類。。。

単純計算で20*10。。。あまり想像したくないですね。。~~私の頭の中ではウォーズマンが回転して謎計算を行っていました。~~

そこで開発者の方々はIaCの導入を検討し、結果的にAWS CDKを導入しました。Terraformなども検討したそうですが、下記を考慮しCDKに決めたそうです。

共通化・個別化のハンドリングの自由度
テストコードで設定編集を安全に適用
全てのスタックでスナップショットテストを実行し、不要な設定変更を監視

また、CDKの導入にあたっては以下を意識したそうです。

IAM Roleの厳密な管理
- CDKで勝手に作られたIAM Roleを使用しないように、使用するIAM RoleはCDK外で作成
- CDK側では作成したIAM Roleを指定して利用
CDKの機能不足
- CDKに欲しい機能が無かった場合、CDKのGitHubリポジトリにissueを立てたり修正することでコントリビュート
体制に合わせたCDKの分割
- サービス全体のリソースを扱うCDK、各サービス用のCDK、というようにCDKを分割
Fargateの管理
- デプロイにはAWS CodeDeployを活用しており、デプロイの度に微妙な差分が出て困っていた。
- そのため、Fargateはカヤック社のOSSであるecspressoで管理